ETL vzor: Vyhněte se serializaci hromadného I/O

bharold

Pokud synchronizujete externí zdroj dat do hostované vrstvy prvků v ArcGIS Online nebo ArcGIS Enterprise, pak je zápis každé periodické změnové dávky něco, co chcete provádět co nejefektivněji.  Jakmile vaše datové sady dosáhnou stovek tisíc nebo milionů prvků, stává se velmi atraktivním vypočítat optimální transakce vložení, aktualizace a smazání, čímž minimalizujete dobu výpadku a riziko selhání transakce.<\/P>

Problém je v tom, že odvození editačních transakcí vyžaduje čtení cílové hostované vrstvy, což je nákladná operace.  Tento blog ukazuje přístup, který se vyhýbá dotazování vaší cílové vrstvy prvků ve prospěch použití exportu souborové geodatabáze export dat, automaticky staženého lokálně, poté efektivně čteného k nalezení změnové dávky, bez dopadu na další úložiště položek.<\/P>

Zde je přístup v akci:<\/P>

BulkUpsert2<\/span><\/span>Vyhýbání se dotazování vrstvy prvků<\/SPAN><\/SPAN><\/SPAN>V dřívějším příspěvku<\/A>  jsem ukázal příklad odvození upsert a delete transakcí pomocí čtení<\/EM> cílové vrstvy prvků, což je serializovaný přístup. Moje cílová vrstva má přes 1M prvků - její čtení trvá několik minut.  Výše uvedené řešení je lepší, vůči téže službě.<\/P>Po stažení příspěvku je k dispozici toolbox s nástrojem ArcGIS Data Interoperability ETL pro Pro 3.5 - viz BulkUpsert2<\/STRONG>.  Nástroj čte CSV soubor na URL (také se vyhýbá serializaci, která je výchozí pro server), ale také přistupuje k obsahu portálu k vyvolání exportu souborové geodatabáze, čeká v cyklu dokud není export dokončen, poté stahuje a čte obsah cílové vrstvy prvků obsah, nikoli službu<\/STRONG><\/EM>, a nakonec maže exportovanou položku (stažená souborová geodatabáze je také automaticky smazána).  Toto je základní funkčnost.  V nástroji jsou dva světle zelené vlastní transformátory.  Jeden EsriOnlineTokenGetter<\/A><\/STRONG> získává token potřebný pro pozdější HTTP volání (pokud pracujete s Enterprise portálem, použijete EsriPortalTokenGetter<\/STRONG><\/A>).<\/P>Spoiler<\/a>

(Zvýrazněte pro čtení)<\/noscript>

Profesionální tip!<\/STRONG>  Stažený blog nyní obsahuje nástroj BulkUpsert2WebConnection<\/STRONG>, který se vyhýbá získávání tokenu použitím webového připojení založeného na OAuth2.   Webové připojení podporuje balíček Esri ArcGIS Connector<\/STRONG>, který poskytuje formát Esri ArcGIS Feature Service<\/STRONG> používaný v pracovním prostoru.  Webové připojení pak používá transformátor HTTPCaller, čímž eliminuje potřebu tokenu.  Pokud vaše organizace vyžaduje vícefaktorovou autentifikaci, získávání tokenu je blokováno a vlastní transformátory nebudou fungovat.  Nyní je doporučenou praxí nainstalovat balíček, vytvořit nové webové připojení a použít ho pro čtení/zápis do feature service a HTTP volání ArcGIS REST API.<\/div>Profesionální tip!  Stažený blog nyní obsahuje nástroj BulkUpsert2WebConnection, který se vyhýbá získávání tokenu použitím webového připojení založeného na OAuth2.   Webové připojení podporuje balíček Esri ArcGIS Connector, který poskytuje formát Esri ArcGIS Feature Service používaný v pracovním prostoru.  Webové připojení pak používá transformátor HTTPCaller, čímž eliminuje potřebu tokenu.  Pokud vaše organizace vyžaduje vícefaktorovou autentifikaci, získávání tokenu je blokováno a vlastní transformátory nebudou fungovat.  Nyní je doporučenou praxí nainstalovat balíček, vytvořit nové webové připojení a použít ho pro čtení/zápis do feature service a HTTP volání ArcGIS REST API.<\/div><\/div><\/noscript><\/div><\/div>Druhý vlastní transformátor je cyklický transformátor, který můžete zkontrolovat na jeho záložce označené FeatureServiceExportLooper<\/STRONG>.  Kontroluje stav exportní úlohy

status každé 2 sekundy dokud není úloha dokončena.  Všimněte si, že délka trvání exportní úlohy závisí na velikosti vaší služby a také na vytížení hostitelského portálu - viděl jsem jak ArcGIS Online zařazuje úlohy do fronty i spouští je okamžitě.  Zde je běh trvající něco málo přes minutu (pouze pro export) v rušném čase v ArcGIS Online:<\/P>FeatureServiceExportLooper<\/span><\/span>FeatureServiceExportLooper<\/SPAN><\/SPAN><\/SPAN>Výsledkem však je významný čistý zisk.  Zde je snímek obrazovky z dřívějšího blogu a serializovaného přístupu - všimněte si délky trvání relace.<\/P>Čtení cílové vrstvy prvků trvá déle<\/span><\/span>Čtení cílové vrstvy prvků trvá déle<\/SPAN>Takto se tedy vyhnout čtení hostovaných vrstev prvků pomocí serializovaného přístupu.  Nyní máte možnost časově náročné konstrukce změnových dávek!<\/<EM>

bharold

Hi Everyone, here is a real run with a day's worth of changes in a 1M-record city address dataset found and written in 2 minutes 41.6 seconds (45 updates, 124 inserts, 34 deletes), less than half the time it would take just to read the target feature service into the tool.  Note I edited the tool to write updates, inserts and deletes, not upserts and deletes, as the asynchronous nature of upsert writes is less suited to small jobs.  Enjoy!

Changeset Write